Problem

ClickHouseRunsRepository.listRunIds / listRuns order results by the composite key (created_at, run_id), but the cursor predicate cut on run_id alone:

.where("run_id < {runId: String}", { runId: cursor })
.orderBy("created_at DESC, run_id DESC")

This is only sound when run_id lexicographic order matches created_at order. run_ids are cuids — only coarsely time-sortable — so when a burst of runs is created within a sub-second window, the two orders can diverge. When they do, the next-page predicate (run_id < cursor, where cursor is the last page element = the smallest created_at, not necessarily the smallest run_id):

• re-includes rows already returned on a previous page (duplicates), and
• skips rows it should have returned (silent data loss).

For bulk replay this caused runs to be replayed more than once (replay has no idempotency guard). For the dashboard and the runs.list API it could silently repeat or skip runs at page boundaries.

Fix

Make the cursor predicate match the composite ordering:

• Cursors now encode the full (created_at, run_id) key as an opaque URL-safe base64 token (base64url({"c":<createdAtMs>,"r":"<runId>"})), and the query cuts on the matching tuple — (created_at, run_id) < (…) forward / > (…) backward.
• The ORDER BY is unchanged, so the query stays aligned with the table's primary key — no performance regression (the tuple range predicate is actually more index-friendly than run_id < alone).
• Cursors are server-issued opaque tokens (the SDK only echoes pagination.next / pagination.previous back), so this needs no client/SDK update. Legacy cursors were the bare internal run_id; they're detected by decode failure (a cuid isn't a valid base64-wrapped JSON payload) and fall back to the old run_id-only predicate, so in-flight cursors keep working and drain naturally. New cursors also no longer expose a bare internal run id.
• listRunIds is now the single cursor-aware list primitive: it returns { runIds, pagination: { nextCursor, previousCursor } }, and listRuns builds on it (one place constructs cursors). Bulk actions consume the same method and advance by pagination.nextCursor, finishing when it's null.
• getTaskRunsQueryBuilder now also selects toUnixTimestamp64Milli(created_at) AS created_at_ms, using a dedicated TaskRunListQueryResult schema. The shared TaskRunV2QueryResult stays run_id-only so the run-engine pending-version lookup (getPendingVersionIdsQueryBuilder, which selects only run_id) doesn't fail validation on a column it doesn't query.

Tests

New runsRepositoryCursor.test.ts (testcontainer-backed, real Postgres→ClickHouse replication):

• forward pagination returns every run exactly once when run_id order is the reverse of created_at order (reproduces the duplicate/skip bug — fails on main; this walk-until-nextCursor-null-and-assert-complete is exactly the bulk action's iteration),
• backward pagination round-trips to the previous page across a boundary,
• legacy bare-run_id cursor still uses the old predicate (backwards compatibility).

The existing runsRepository suites (part1–4) still pass; part4's count new runs with listRunIds test was updated for the new { runIds, pagination } return shape, and the clickhouse taskRuns query-builder snapshots were regenerated for the added created_at_ms column.

Notes

• Separate, pre-existing issue (out of scope, not introduced here): listRuns' backward display-slicing (rows.slice(1, size+1) when hasMore) has an off-by-one that can return a straddled page. Tracked separately.

🤖 Generated with Claude Code